By desugaring stdlib dependencies this early in the pipeline, we
are able to touch much less of Cargo. On the other hand, "stdlib"
is no longer a valid version for the purpose of [[replace]]-ing.
https://github.com/rust-lang/rfcs/pull/1133#issuecomment-223746363
This isn't so bad, because one can still replace the dep the if one
knows the version number of the normally-resolved stdlib version.
More philosophically, replacements are done after solving version
requirements, at which point version requirements are gone and only
concrete resolved versions remain. "stdlib", in delegating the
choice of version elsewhere, is thus more of a version requirement
than version.
https://github.com/rust-lang/rfcs/pull/1133#issuecomment-230950635
Cargo cannot express dependencies on "A compiler with support for X." This affects far more > than just the sysroot - every crate that uses a feature that went through stabilization post 1.0 should make use of such a thing. The sysroot getting a free pass on this papers over it just enough that it remains unfixed and painful for everyone else, IMO.
The sysroot uses unstable features internally, because it knows the rustc version it is built with. This is both a subset of the above, and hostile to independent compiler implementations. A principled solution to the above could easily encompass the unstable features used (heck, Cabal manages it!).
Not needing to recompile it for each crate. This is something that could be amply solved in the general case by Cargo keeping some global cache of built crates indexed by target, version, and features.
they mention cabal specifically and frequently. i suspect simon peyton-jones's involvement
